NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/6139

Internet Message Format | 1996-08-05 | 3.5 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.c
Subject: Re: a pointer problem
Date: 22 Feb 1996 11:16:19 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <4errk0$[e-mail]> <[e-mail]> <4et96h$[e-mail]> <4g1a9l$[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <4g1a9l$[e-mail]>,
Ramses Youhana <[e-mail]> wrote:
>> I would and sometimes do count on initialization of static and global
>> variables, as long as I work with an ANSI C compiler. Initialization
>> happens "as if" through assigning 0 to the variable, so this kind of
>> initialization is save for pointers and floating point variables, too.
>
>It is dangerous to rely on the compiler to do initialisation of static
>and global variables in embedded systems.  This is usually the case when

It's not the compiler that does it. The whole environment of the program has to
cooperate to guarantee the behavior. Linker, loader, etc. All the tools used in
a standard conforming implementation have to work together to meet the
standard. If any link in this chain of tools is broken, the implementation is
non conforming.

>you write your own boot code and don't include the appropriate routine(s)
>which read the data out of the appropriate section (sometimes called the
>IDATA or INITDATA section) and copies to the appropriate RAM locations
>to initialise your variables.
>
>I always find it better (and safer) design to perform my own initialisations
>in an initialisation function.

The ANSI C standard requires that unitialized statics are zero, and it defines
the behavior of global initializations.  Furthermore, this doesn't mean that
you can just store a zero bit pattern in an unitialized data area. If you have
any unitialized data types that have zero values that don't correspond to
all-zero bit patterns, these have to be prepared analogously to initialized
variables. If I leave a global pointer uninitialized, it will be a null pointer
regardless of what bit pattern is used to represent it. Likewise for
uninitialized floats.

If your environment does not set up these conditions for the C program,
embedded or not, it is broken. If you write your own boot code, which launches
the embedded C program, you have to make sure that it satisifies the weakest
preconditions for running that program. If you want to deviate from the
language standard, that is up to you, of course, but you will probably have a
hard time integrating existing code that relies on the use of private static
objects, since you will have to comb through every piece of code looking for
static declarations, and including their initialization in a special routine.
Of course, if any of these are private to functions, you will have to move them
outside so that they are in the scope of the initializing function, and take
care to resolve any name clashes...

... isn't it easier to just write your boot code properly in the first place?


You can't write programs that defend themselves against all possible broken
compilers and environments. If you start initializing statics using explict
code, where does the paranoia stop? Do you start using gotos everywhere just in
case if(), while() and for() generate buggy code? What do you do if you don't
trust that the environment will give you your string literals, or integer
literal constants in statements like char *x = "foo" or int y = 3?
--